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CALL CENTER 

Field of the Invention 

The presmt invention relates to call centers logically composed of a number of 
woikgroups. In particular, but not exclusively, flie present invention relates to call centers 
capable of handling both traditional telephone calls and VoIP fVoice over BP") calls, 

^fi^ma ry of flie Invention 

According to the present tnvoition, there is provided a call center system with multiple 
workgroi^s, each workgroup having a routing amtroller comprising: 

— routing-data generating means operative to derive worikgroup routing data 
indicative of tfie suitability of destinations within the workgroup for receiving 
calls; 

— transfer means for passing the workgroup routing data directly or indirectly to 
the routing controllers of the other workgroups; 

— storage means for storing tfie workgroiq) routing data of all operative 
workgroups, and 

— global routing means arranged to: 

— receive a routing request in reject of a call incoming to the call center, 

— determine fix>m the stored routing data for all operative workgroups 
\^ch worlcgroup is most suited to handle a calU and 

— respond to the routing request accordingly. 

Brief Description of the Drawings 

A call center embodying the invention will now be described, by way of non-limiting 
example, with reference to the acconq>anying diagrammatic drawings, in whidu 
. Figure 1 is a diagram of the call coiter showing its relation to a PSTN and an IP- 
based network; 

. Figure 2 is a diagram similar to Figure 1 showing message paths and call routing 
during connection of a PSTN-originating call to a call-center agent; and 
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• F^re 3 is a diagram similar to Figure 1 showing message paths and call routing 
during connection of a network-originating VoIP call to a call-center agent 

Best Mode of Carrying Ont the Invention 

The Figure I call center con^>rises three logical work groups WGl, WG2, WG3 
(generically referred to below as " WG") that may be co-located or geographically 
dispersed. The call center interfaces both with a traditional telephone network 10, and 
with an inter-connected network 20 of IP-based networks (this network of networks 
being hereinafter referred to simply as die "IP network** 20). By way of example, the 
telephone network 10 is here shown as a PSTN (analog and/or ISDN based), but may 
equally be a PLMN, a private network, or similar tel^hone network. The JP network 
20 may be the Internet, an intranet, or similar IP-based network. 

The PSTN includes as well as normal switches (not shown), a service switching point 
(SSP) 22 capable of determining that a particular service is required for a call and for 
sending a service request to die service control subsystem of the PSTN. In the present 
example, the service control subsyst^ comprises a "WebSCP" 23, namely a service 
control point (SCP) vnth a web inter&ce for retrieving service data and logic ov^ the 
IP network 20 using the web HTTP protocol , Further details of W*SCP 23 are givai 
in our published International Application WO97^2210 which is incorporated hereui 
by refcrmce. In fact, any SCP with an interface to the IP network 20 may be used for 
component 23. Whatever the precise form of SCP 23, the SCP will respond to a service 
request fiom SSP 22 with a number to be used for routing 4e call in respect of which 
the service request was made. As will be explained hereinafter, in die present case the 
SCP23 determines its response in dependence on data it receives back fiom a query 
sent out over the IP network 20. 

Each workgroup WG comprises a LAN 11 to which are connected a plurality of agent 
wodcstations 12, a media gateway 13, a media server 14, a gatdceeper 15 with an 
associated web server 16, and a router 17. Each workgroup WG coimects via its 
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gateway 13 to the PSTN 10, and via its router 17 to the IP network 20 of which it 
substantially forms a part. 

Each workgroup can thus receive calls from both the PSTN and from tOTninals 21 
5 (such as a PC) linked to the IP network 20. Calls from the PSTN are received at the 
gateway 13 and are converted into a VoIP call for routing to a selected agent 
woikstationl2 over LAN 10. VoIP calls from terminals 21 are received at the router 17. 

By way of example, the VoIP calls will be taken to be in accordance with the H.323 
) standard though other VoP standards can altonativdy be iised. 

Each agent workstation 12 is cq>able of handling VoIP calls and, m addition, can 
receive caller data for screen display to the ageat This caller data can be derived from 
any appropriate source such as a calla: database (not shown) holding known 
information about a caller, or from an information-collecting resource arranged to 
gather caller data as an initial phase of a current call (for example, using the media 
server or a related website interaction with the caller). 

Calls received at a workgroup WG may instead of being routed to an agOTt 
workstation, be routed to the media server for delivery of voice armouncemmts (more 
geneially for every cqiability involving data streaming) and/or the collection of usct 
input. 

Although each workgroiq) WG has been described as bdng composed of elemmts all 
connecting with the same LAN 10 , it would be possible to remotely locate elemrats. 
For example, one or more agCTt workstations may reside at a remote location on a 
diflFerent LAN or at die end of an ISDN link. The physical location of the components 
is not itself of in^jortance, but it is necessary for the gatekeeper 15 to kaow (or be able 
to deteraiine) the IP address of the components of the same worisgroi^ WG. 

Considwation will next be given as to how call control is effected for the call center. At 
a basic level, control of the VoIP calls in the IP network 20 (whether PSTN originating 
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or temiinal-originating) is effected in known manner by gatekeepers (eg gatekeepers 
1 5) that exchange control messages (for example in accordance with the Inter- 
(jateKeeper protocol of the H.323 standard). Thus» the gatdceeper 15 of a workgroup 
WG will know the IP addresses of the associated agent workstations 12 and can return 
5 the IP address of an available agrat woricstation in response to a request as to where to 
route an incoming call. 

At a higher level, the gatdkeq>er 1 5 of a workgroup WG also performs a workgroup- 
level control function by determining priorities betwera its agent resources. More 

10 particularly, the gatekeq^er 15 keeps track of the availability of agents at the agent 
workstations ("availability" being dqiendent on Victors ranging ftom simple presence, 
to length of call-waiting queue). Additionally, the gatekeeperlS will store policies and 
data relating to agent skill level and time-of day routing. Based on all these Actors 
(and potmtially fiutiier Actors), the gatekeeper 15 will construct a routing table, in a 

1 5 manner well understood by persons skilled in the art, which it stores. This routing table 
is then used by the gatekeq)er to determine to which workstation 12 to allocate a call 
(tfie call may not be inmiediately be routed to that workstation but may need to be 
queued and/or connected to the media server 14 as a preliminary step). The gatekeeper 
1 5 updates its routing table at frequent intervals (or whenever a relevant parameter 
20 changes). 

In the preset call center, tibe gatekeepers 1 5 of all the workgroi^>s WG are arranged to 
exchange their routing tables at fiequent intervals, each gatekeeper 15 storing the 
routir^g tables for all workgroiq)S WG. The exchange of routing tables (indicated by a 
25 dotted ellipse in Figure 1) can be effected either using IGCP (in which case the 

gatekeq>ers themselves efifect the exchange) or using HTTP (in which case it is the web 
servers 16 associated with each gatdceeper 15 that effect the exchange). Any 
distribution topology may be used for the exchange (ring, fully meshed, etc.). 

30 Since each gatdceeper 1 5 now has access to the routing tables for all workgroups, each 
gatekeeper can make global routing decisions b^ween the workgroups, that is, decide 
which workgroup is best suited to handle any particular call The algorithm used to 
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determine which workgroup is best suited should be the same for each gatekeeper to 
ensure consistency of decision b^een them; how such an algorithm may make its 
selection is well understood by persons skilled in the art and will therefore not be 
detailed. 

Having described the basic structure and control functions of the call center, two 
exanq)Ies of its operation will now be given. 

Figure 2 illustrates how a call fiom a PSTN phone 30 is handled. The caller calls a 
number N (here given as "0800 123456*0 that indicates to the SSP 22 that the caller 
wishes to place call this exanq)le, a fiee-phone call) to the call crater. The number N 
may already designate a particular workgroup or it may simply designate flie call ccatec 
as a whole. Tlie SSP 22 makes a service request to the SCP 23 which, in turn, makes a 
request to one of the HTTP servers 16 of the call-center workgroups asking for the 
telephone number to which the caU should be routed. The server 16 contacted may be 
dq)endOTt on the number N or may chosen according to some predetermined ordering 
(for example, on a round robin principle). In the present case, it is the server 16 of 
workgroup WGl that is contacted (see thick dashed line 3 1 in Figure 2). On receiving 
the request, the servo: 16 passes it to its gatekecpo: 15 which then determines fiom the 
routing tables available to it, which workgroup WG is best suited to handle the call (in 
this example. workgroiq> WG2). The telephone numbw of this workgroup is then 
returned by the senra: 16 to the SCP 23 which, in turn, passes it back to the SSP 22. 
SSP 22 ttien routes the call fiom phone 30 to the gateway 13 of wodcgroup WG2 at the 
number passed back to the SSP 22 fiom the gatekeeper 15 of workgroup WGL 

The gateway 13 then asks the gatekeeper 15 of workgroup WG2 where it should route 
the call i.e. to which agent workstation 12 or media server 14 (see dashed line 32). The 
gatekeeper 1 5 responds appropriately and the gateway 1 3 then passes the call as a VoIP 
call over the LAN 1 1 to the designated agent workstation/media server. 

The route of the call fiom phone 30 to the agent woikstation is indicated by a diain- 
dashed line in Figure 2. 
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If during this call set up process, SCP 23 had been unable to obtain a response from the 
server 16 of workgroup WGl, then it will try contacting the server 16 of a different 
workgroup acccmling to a default schedule held by the SCP. If the second choice server 
5 also foils to respond, the SCP may try a third server 1 6, This fallback messaging is 
indicated by light dashed lines 33, 34 in Figure 2. 

This fault tolerant behaviour of the call center is made possible by the fact that the 
routing tables for all the workgroups are available at each workgroup whereby global 
10 routing decisions can be made by any of the gatekeepers IS. 

Figure 3 shows tfie handling of a call placed from terminal as a VoIP call (for example 
a "Help Desk" call). In this case, the gatdceqier 40 of the LAN on which the 
terminal 21 is situated contacts a gatekeeper 15 of one of the workgroiq)s - in this case 

15 workgroup WG3 (see dashed line 43), Hie gatekeeper of workgroup WG3 determines 
from all the workgroiq) routing tables available to it ttiat the call should be handled by 
workgroiq) WG2 and informs the gatekeepar 40 accordingly. Gatekeeper 40 then 
contacts the gatekeepCT 15 of workgroiq) WG2 (see dashed line 44) asking it for the IP 
address of the agent/media servo- to which the VoIP call should be routed Gatekeeper 

20 15 returns the IP address of a particular agent workstation 12 in workgroup WG2 and 
gatekeeper 40 passes this information back to terminal 21 . Terminal 2 1 then establishes 
a VoIP call to the appropriate agent workstation (see chain-dashed line). 

It will be s^preciated that if the most suitable workgroup was the one first contacted 
25 (workgroup WG3 in the present example), the gatekeeper of that workgroup will 
directly respond with tfie IP address of the agent (or other resource) to be contacted. 
Indeed, since the first contacted gatekeeper 15 has available to it the routing table for 
the workgroup determined by it to be the most suitable, it can in ttieory directly 
determine and return the IP address of the agent/resource to receive the call (assuming 
30 it had been passed these addresses). However, this is not consistent with the intended 
operation of the gatekeepers whidi are generally in charge of routing VoIP calls within 
their related domains. Furthermore, it is not necessarily the best strategy to adopt since 
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although the routing tables will be reasonably current, they may not have the very latest 
information concerning agent situation in every workgroup and it will generally be 
better to leave final workgroup-internal routing up to the gatdkecp&c of the workgroup 
selected, 

With respect to how the gatekeepCT 40 determines ^ch gatekeeper 1 5 to contact 
initially, a numbw^ of possibilities exist. Thus, gatekeeper 40 could have previously 
registered with the call cento- to be informed of the IP addresses of the gatekeepers 1 5; 
the gatekeeper 15, knowing the addresses of the gatekeepers 15 could then eithor select 
one according to a predetermined policy or broadcast to all gatekeepers 15 (in v/lnch 
case, gatekeeper 40 would then utilise only the first response only). 

As with calls placed bom the PSTN, calls placed form a terminal 2 1 benefit from the 
routing information redundancy inhemt in the call coiter whereby should the 
contacted gatdceeper 15 be down, the other gatekeepers 15 can be contacted to give the 
same global routing dedsioiL 

Various modifications arc, of course, possible to the arrangement described above. For 
example, the SCP 23 ratfa^ than talking to the workgroups WG xising HTTP, could talk 
IGCP directly to the gatekeepCTs 15 thereby avoiding the need for the senrers 16, 
Furthermore, rather than the fiill routing table of each woikgroi^ being passed to the 
other workgn)iq>s, a subset of the full routing table could be passed giving suflScient 
information to enable the most suitable workgroup to be selected according to die 
selection algorithm in use. ' 

The network 10, rather than bdng a telephone network, could, in fact, be any switched 
telecommunications network . The network 20 may also be a non IP-based packet 
network. 
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CLAIMS 

1 . A call center system with multiple workgroups, each woikgroiq) having a routing 
5 controller con4>rising: 

— routing-data generating means operative to derive workgroup routing data 
indicative of the suitability of destinations within the workgroup for receiving 
calls; 

— transfer means for passing the workgroup routing data directly or indirectly to 
10 the routing controllers of the other workgroups; 

— storage means for storing the workgroiq) routing data of all c^erative 
workgroi^s, and 

— global routing means arranged to: 

— receive a routing request in req>ect of a call incoming to the call center, 
15 — determine fiom the stored routing data for all operative workgroups 

which workgroup is most suited to handle a call, and 

— respond to the routing request accordingly. 

— respond to the routing request accordingly. 

20 2. A call cent^ systm according to claim 1, whwein at least one of the workgroups is 
adapted to receive calls fix>m the pubhc telephone network and at least one of the 
workgroups is adq)ted to receive calls from a data network as a VoIP call. 



25 3. A call center system according to claim 1 , wherein at least one workgroup is adapted 
to receive calls both from a telephone network, and from a data network as VoIP calls, 

4. A call center according to claim 1, wherein the workgroup further comprises: 

— a LAN to wiiich said routing controller is connected, 

30 - a first interface for interfecing with a data network for receiving VoIP calls, 

— a second interface for interfacing with a telephone network and for converting 
calls received herefrom into VoIP calk, and 
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- agent workstations for handling calls, 
said routing request being received through said first interface. 
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